Yes I understand, so in #1303 I used to code differents things to prevent sending to relabel too many file/path
Bgilbert ask me for a better way to do that by finding the "root" of setting file/path to relabel, that's what this PR is intended to do.
if I well understand, the "action" for relabelling (setfiles) already handle this case ?

Yes, setfiles itself will work just fine as is.

OK, read some of the discussions in #1303 now. That PR is introducing code which will make it easier to have multiple requests for relabeling the same dirs unless the code is made more complex to handle that.

So I'm cool with embedding handling for this into the relabeling bits directly. For that, let's do

maybe a cleaner approach would be to switch from a slice to a set (really, a map[string]struct{}).

instead?

That said, I'd consider this orthogonal to #1303. You can go ahead and simplify the code there to just call s.relabel() "inefficiently" for now and we don't have to block it on this necessarily. (Big picture, we're not talking about that many duplicates here, right? Something like user unit * (users for unit - 1) summed across all user units?)

Yes, we don't speak about a ton of files, you're right :) I just dive in the systemd.unit code and I don't know the amount of files/paths that have to be relabelled when setfiles is called
When I went into debug mode, I saw some duplicates, and we (@bgilbert and I) started to avoid that. (e.g. : #1318 )

So I'm cool with embedding handling for this into the relabeling bits directly. For that, let's do

maybe a cleaner approach would be to switch from a slice to a set (really, a map[string]struct{}).

instead?

I agree for using map against slice but to be honest, I felt lazy handling that 😄 will give it a try ;)

Sorry, one final thing. Let's tweak the commit message to something like:

files: track relabeling using set instead of slice

That way we avoid passing the same path to `setfiles` multiple times.

?

Nice work @Nemric!